System and method for pool-based identity generation and use for service access

ABSTRACT

A computer-implemented system and method for pool-based identity generation and use for service access is disclosed. The method in an example embodiment includes seeding an identity generator with a private key; retrieving independently verifiable data corresponding to a service consumer; using the independently verifiable data to create signed assertions corresponding to the service consumer; generating a non-portable identity document associated with the service consumer, the identity document including the signed assertions; signing the identity document with the private key; and conveying the signed identity document to the service consumer via a secure link.

BACKGROUND

1. Copyright Notice

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever. The following notice applies to the software and dataas described below and in the drawings that form a part of thisdocument: Copyright 2006-2008, eBay Inc., All Rights Reserved.

2. Technical Field

This disclosure relates to methods and systems supporting computing anddata processing systems. More particularly, pool-based identitygeneration and use for service access.

3. Related Art

In Services Oriented Architecture (SOA), there are many communicatingservices that are deployed in several machines. In large-scaleenterprises, like eBay, eTrade, or Google for example, there could bethousands of different services deployed in thousands of machines. It ismost efficient if these services are allowed to communicate with eachother. If these services are allowed to communicate with each other,various types of access controls and security checks will be required.These access controls and security checks can include, for example,service authentication, service authorization, and rate limiting. Forexample, a ‘billing service’ (caller service) can be authorized toaccess or call a ‘rating calculator service’ (callee service), while an‘about me service’ will not be so authorized.

For the security checks described above, the callee service needs to beable to identify the caller service. For example, the ‘rating calculatorservice’ (callee service) needs to be able to identify the ‘billingservice’ (caller service) prior to enabling access to the calleeservice. Human users can be easily authenticated by prompting for apassword, for example. However, the same mechanisms used for identifyingand authenticating human users cannot be used for identifying andauthenticating computer-implemented services or software processes orapplications. Services and/or applications cannot use passwordidentification/authentication, such as by retrieving a password fromdisk storage; because, the passwords can be easily stolen and used forunauthorized purposes. In other words, passwords represent an example ofundesirable portable credentials that cannot be used safely foridentification/authentication of computer-implemented services orsoftware processes or applications. Conventionalidentification/authentication mechanisms do not support a mechanism forproviding non-portable credentials that can be used foridentification/authentication of computer-implemented services orsoftware processes or applications.

U.S. Patent Application No. 2005/0223109 describes a system whereinservices such as product services, real-time services, and commonservices are deployed in a services oriented architecture. Theseservices may, for example, be deployed for use in a variety ofenterprise data integration functions.

U.S. Patent Application No. 2007/0011126 describes a service-orientedarchitecture (SOA) and accompanying method. In one embodiment, the SOAincludes one or more service requesters coupled to one or more serviceproviders via a bus. The bus includes runtime-binding functionality tofacilitate interaction between the one or more service requesters andthe one or more service providers. A registry, which stores informationpertaining to a service provided by the one or more service providers,communicates with one or more service providers and/or requesters andthe bus. In a more specific embodiment, bus includes aService-Integration Bus (SIB) that includes a Service-Factory (SF)module for facilitating implementing the runtime binding functionalityand for selectively invoking the service. Functionality of the SOA isstrategically organized into various tiers and layers, including arequester tier, a provider tier, a business-process services tier, aninfrastructure-services tier, an SIB layer, a persistence layer, and soon.

Thus, a computer-implemented system and method for pool-based identitygeneration and use for service access are needed.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments illustrated by way of example and not limitation in thefigures of the accompanying drawings, in which:

FIG. 1 is a block diagram of a network system in which an embodiment mayoperate.

FIG. 2 is an event diagram showing a sequence of operations in oneexample embodiment.

FIGS. 3-6 illustrate processing flow diagrams for various exampleembodiments.

FIG. 7 shows a diagrammatic representation of a machine in the form of acomputer system within which a set of instructions, for causing themachine to perform any one or more of the methodologies discussedherein, may be executed, according to an example embodiment.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of some example embodiments. It will be evident, however,to one of ordinary skill in the art that the present invention may bepracticed without these specific details.

As described further below, according to various example embodiments ofthe disclosed subject matter described and claimed herein, there isprovided a computer-implemented system and method for pool-basedidentity generation and use for service access. Various embodiments aredescribed below in connection with the figures provided herein.

In particular embodiments, an identity generator is provided to generatesigned identity documents for deployment on target machines.Authentication can be based on the identity documents in combinationwith other independently verifiable data and tests performed on theidentity documents and independently verifiable data. One example of theindependently verifiable data is an Internet Protocol (IP) address of anapplication server or a computing system acting as a service consumer.The IP address can be independently verified from the TCP socket headeras the raw socket packet structure contains the remote IP address.Additionally, the IP address can be independently verified by extractingthe x-Forwarded HTTP (Hypertext Transfer Protocol) value inserted by avirtual IP address forwarding processor. Credentials can be generated byan authentication authority server upon successful completion of thetests on the identity documents and independently verifiable data. Thesecredentials can then be used by other systems to access services andapplications; because, the credentials can be trusted given thevalidation processing provided by the authentication authority serverusing the tests performed on the identity documents and independentlyverifiable data.

Referring to FIG. 1, a diagram illustrates an example embodiment of acomputer-implemented system for pool-based identity generation and usefor service access. During a build time or initial system/servicedeployment time 101, an identification authority computing system oridentity generator 100 can generate an identity for each of a pluralityor pool of service consumers 105. The generated identity for aparticular one of the service consumers 105 is maintained in an identitydocument that can be conveyed to the particular service consumer 105 byidentity generator 100 via a secure link. A secure deployment tool, suchas TIVOLI, can be used to perform the initial system/service deployment101 with the identity document generated by the identity generator 100.Various embodiments for creating the identity document are described inmore detail below.

The identity generator 100 can be initially seeded with a certificateand a private key used for signing the identity documents. The identitygenerator 100 can be maintained in a secure environment to protect thecertificate and private key from being compromised. The identitydocument can be well protected by having read permission only granted tothe service process (application) user name. The identity document isgenerated with signed assertions on the service host attributes, such asservice names, IP addresses, and validity. As such, the identitydocument serves to bind the particular processing device at a particularIP address to the generated identity document in a secure manner. Oncegenerated, the identity document can be digitally signed. As such, theidentity document is a non-portable credential that cannot be used fromother hosts. The identity document is only useful for identifying aparticular processing device at a particular IP address.

In a particular embodiment, a well-known protocol, such as the securityassertion markup language (SAML), can be used to communicate identitydocuments and credentials among the various components of the system.Conventional SAML is an XML (Extensible Markup Language) standard forexchanging authentication and authorization data between securitydomains, that is, between an identity provider (a producer ofassertions) and a service provider (a consumer of assertions). SAML is aproduct of the OASIS Security Services Technical Committee. It will beapparent to those of ordinary skill in the art that other protocols maybe used with various embodiments.

The single most important problem that SAML is trying to solve is theWeb Browser Single Sign-On (SSO) problem. Single sign-on solutions areabundant at the intranet level (using cookies, for example); but,extending these solutions beyond the intranet has been problematic andhas led to the proliferation of non-interoperable proprietarytechnologies. SAML has become a standard underlying many web SingleSign-On solutions in the enterprise identity management problem space.However, SAML does not specify the implementation of localauthentication services; indeed, SAML does not care how localauthentication services are implemented (although individual serviceproviders most certainly will). A service provider relies on anauthentication authority 110 to identify the service consumer as will bedescribed in more detail below.

Thus, referring again to FIG. 1, the signed identity document generatedby the identity generator 100 at initial system/service deployment time101 can be conveyed to and stored by each service consumer 105. Oncethese identity documents are resident in each service consumer 105, arun time mode 102 can be initiated to enable the service consumers 105to access and use a plurality of service providers 120 for theparticular processing needs of the service consumers 105.

As well known to those of ordinary skill in the art, an authorizationservice (e.g. a role-based access control system or RBAC server) 115 canbe configured to specifically grant or deny access to and/or use ofparticular services provided by the service providers 120 to particularservice consumers 105. In this manner, a properly identified serviceconsumer 105 can be granted or denied access to particular services ofservice providers 120 based on the configured information inauthorization service 115. However, the service authorization providedby the authorization service 115 assumes that the identity of therequesting service consumer has already been verified. This serviceconsumer 105 identity verification stage is a focus of a particularembodiment as described in more detail below.

Referring still to FIG. 1, once the signed identity document generatedby the identity generator 100 at initial system/service deployment time101 is stored by each service consumer 105 and a system run time mode102 is initiated, each service consumer 105 can thereafter begin to usevarious services provided by the service providers 120. However, priorto accessing the services provided by the service providers 120, theservice consumers 105 must obtain credentials from an authenticationauthority 110. The authentication authority 110 is a processing entitythat is trusted by the service providers 120. As such, a serviceconsumer 105 providing credentials validated by the authenticationauthority 110 can obtain access to or use of a requested service,assuming such service access or use is authorized by the authorizationservice 115. Therefore, service providers 120 do not need to access theidentification authority 100 to validate the identity of a serviceconsumer 105.

During a system run time mode 102, a service consumer 105 can requestcredentials from the authentication authority 110. As part of thisrequest for credentials, the service consumer 105 provides its identitydocument, or a portion thereof, to the authentication authority 110. Theauthentication authority 110 can use a public key to verify the identitydocument. Further, the authentication authority 110 can validate theidentity document by verifying the content of the identity documentagainst independently verifiable data. As described above, theindependently verifiable data can include an Internet Protocol (IP)address of the service consumer 105. Thus, the service consumer 105 IPaddress, name, attributes, or other identifying information that wasincluded in the identity document originally generated by the identitygenerator 100 can be validated by the authentication authority 110 oncethe authentication authority 110 obtains the independently verifiabledata and matches the data with the corresponding data in the identitydocument of the service consumer 105. If the authentication authority110 is able to match the independently verifiable data with thecorresponding data in the identity document of the service consumer 105,the authentication authority can generate credentials for the serviceconsumer 105 and convey the credentials to the service consumer 105. Thecredentials created for the service consumer 105 by the authenticationauthority 110 can include assertions of the validity of the identity ofthe service consumer 105. These credentials can be digitally signed bythe authentication authority 110 using conventional methods.

Once the service consumer 105 obtains valid credentials from theauthentication authority 110, the service consumer 105 may thereafterrequest access to or use of the services provided by the serviceproviders 120. When a service consumer 105 wishes to use a service ofservice providers 120, the service consumer 105 makes a request for theservice. The service request includes the credentials for the requestingservice consumer 105 as obtained from the authentication authority 110.The service request with credentials is conveyed to the particularservice provider 120. A SAML communication can be used for this servicerequest.

When the service provider 120 receives a request for service withcredentials from a service consumer 105, the service provider 120 canrespond in various ways. First, the service provider 120 can verify thecredentials created by the authentication authority 110 using a publickey or certificate. Because the service provider 120 trusts theauthentication authority 110 to properly validate the identity of theservice consumer 105, the service provider 120 may accept the identityof the service consumer 105, given an apparently valid credential withthe proper content and assertions. Optionally, the service provider 120can validate the credentials by verifying the content of the credentialsagainst independently verifiable data. As described above, theindependently verifiable data can include an Internet Protocol (IP)address of the service consumer 105. Thus, the service consumer 105 IPaddress, name, attributes, or other identifying information that wasincluded in the credentials originally generated by the authenticationauthority 110 can be validated by the service provider 120 once theservice provider 120 obtains the independently verifiable data andmatches the data with the corresponding data in the credentials of theservice consumer 105. If the service provider 120 is able to match theindependently verifiable data with the corresponding data in thecredentials of the service consumer 105, the service provider 120 canaccept the identity of the service consumer 105.

Once the identity of the service consumer 105 is verified by the serviceprovider 120, given the credentials as part of a service request, theservice provider 120 may access the authorization service 115 to checkthe access controls previously configured for the service consumer 105in regard to the requested service. If the requesting service consumer105 is authorized to access or use the requested service as determinedusing the authorization service 115, the service provider 120 can grantaccess or use of the requested service to the requesting serviceconsumer 105. Thereafter, the requested service and related data isprovided to the requesting service consumer 105. Using a similar processas described above, the service consumer 105 can access and/or use anyof the authorized services provided by the service providers 120. Ineach request for service, the service provider 120 does not need toaccess the identity generator 100 or the authentication authority 110 tovalidate the identity of the service consumer 105. Rather, because ofthe novel configuration and processing of a particular embodiment, theservice providers 120 can trust the authentication authority 110 tovalidate the identity of the service consumers 105 and generate validcredentials for the service consumers 105. Further, the authenticationauthority 110 can trust the identity generator 100 to generate valididentity documents for the service consumers 105.

FIG. 2 is an event diagram showing a sequence of operations in oneexample embodiment. In a first operation 210 of the example embodimentshown in FIG. 2, the identity generator 100 generates an identitydocument for a service consumer 105 and sends the identity document tothe service consumer 105. This operation typically occurs at initialsystem/service deployment time 101. In the next operation 215 of theexample embodiment, the service consumer 105 can use the identitydocument, or a portion thereof, to generate a request for credentialsthat can be sent to an authentication authority 110. Once thecredentials are received back from the authentication authority 110, theservice consumer 105 can use these credentials for requesting servicesfrom a service provider 120 in subsequent operations during system runtime 102. In the next operation 220 of the example embodiment, theauthentication authority 110 receives a request for credentials from theservice consumer. The request for credentials will include the identitydocument, or a portion thereof, as generated by the identity generator100 for the service consumer 105. The authentication authority 110 canuse a public key to verify the portion of the identity document thatcontains independently verifiable data associated with the serviceconsumer 105. As described above, the independently verifiable data caninclude an IP address of the service consumer 105. During operation 220,the authentication authority 110 can validate the identity document, orportion thereof, received in the request for credentials by verifyingthe content of the identity document against independently verifiabledata. The authentication authority 110 can obtain the independentlyverifiable data and match the independently obtained data with thecorresponding data in the identity document, or portion thereof, of theservice consumer 105. If the authentication authority 110 is able tomatch the independently verifiable data with the corresponding data inthe identity document of the service consumer 105, the authenticationauthority can generate credentials for the service consumer 105 andconvey the credentials to the service consumer 105 in operation 225shown in FIG. 2. The credentials created for the service consumer 105 bythe authentication authority 110 can include assertions of the validityof the identity of the service consumer 105. These credentials can bedigitally signed by the authentication authority 110 using conventionalmethods.

In the next operation 230 of the example embodiment, the serviceconsumer 105 can use the credentials received from the authenticationauthority 110, or a portion thereof, to generate a request for servicefrom a service provider 120. The service request with credentials, orportion thereof, is conveyed to the particular service provider 120 inoperation 230. A SAML communication can be used for this servicerequest.

In the next operation 235 of the example embodiment, the serviceprovider 120 receives a request for service with credentials from aservice consumer 105. In response to the service request, the serviceprovider 120 can respond in various ways. First, the service provider120 can verify the credentials created by the authentication authority110 using a public key. Because the service provider 120 trusts theauthentication authority 110 to properly validate the identity of theservice consumer 105, the service provider 120 may accept the identityof the service consumer 105, given an apparently valid credential withthe proper content and assertions. Optionally, the service provider 120can validate the credentials in operation 235 by verifying the contentof the credentials against independently verifiable data. As describedabove, the independently verifiable data can include an InternetProtocol (IP) address of the service consumer 105. Thus, the serviceconsumer 105 IP address, name, attributes, or other identifyinginformation that may have been included in the credentials originallygenerated by the authentication authority 110 can be validated by theservice provider 120 once the service provider 120 obtains theindependently verifiable data and matches the data with thecorresponding data in the credentials of the service consumer 105. Ifthe service provider 120 is able to match the independently verifiabledata with the corresponding data in the credentials of the serviceconsumer 105, the service provider 120 can accept the identity of theservice consumer 105.

In the next operation 240 of the example embodiment, the serviceprovider 120 may access the authorization service 115 to check theaccess controls previously configured for the service consumer 105 inregard to the requested service. If the requesting service consumer 105is authorized to access or use the requested service as determined usingthe authorization service 115, the service provider 120 can be given theauthority by authorization service 115 to grant access or use of therequested service to the requesting service consumer 105 in operation245. Thereafter, the requested service and related data is provided tothe requesting service consumer 105 in operation 250. Using a similarprocess as described above, the service consumer 105 can access and/oruse any of the authorized services provided by the service providers120. In each request for service, the service provider 120 does not needto access the identity generator 100 or the authentication authority 110to validate the identity of the service consumer 105. Rather, because ofthe novel configuration and processing of a particular embodiment, theservice providers 120 can trust the authentication authority 110 tovalidate the identity of the service consumers 105 and generate validcredentials for the service consumers 105. Further, the authenticationauthority 110 can trust the identity generator 100 to generate valididentity documents for the service consumers 105.

FIG. 3 illustrates a processing flow diagram for an example embodiment.In the embodiment 310 shown, a pool-based identity generation apparatusfor service access performs the steps of: seeding an identity generatorwith a private key (processing block 315); retrieving independentlyverifiable data corresponding to a service consumer (processing block320); using the independently verifiable data to create signedassertions corresponding to the service consumer (processing block 325);generating a non-portable identity document associated with the serviceconsumer, the identity document including the signed assertions(processing block 330); signing the identity document with the privatekey (processing block 335); and conveying the signed identity documentto the service consumer via a secure link (processing block 340).

FIG. 4 illustrates a processing flow diagram for another exampleembodiment. In the embodiment 410 shown, a pool-based identitygeneration apparatus for service access performs the steps of:retrieving a non-portable identity document associated with a serviceconsumer, the identity document including signed assertionscorresponding to independently verifiable data of the service consumer(processing block 415); generating a request for credentials includingat least a portion of the content of the identity document (processingblock 420); sending the request for credentials to an authenticationauthority (processing block 425); and receiving credentials from theauthentication authority (processing block 430).

FIG. 5 illustrates a processing flow diagram for another exampleembodiment. In the embodiment 510 shown, a pool-based identitygeneration apparatus for service access performs the steps of: receivinga request for credentials from a service consumer, the request forcredentials including at least a portion of the content of anon-portable identity document associated with the service consumer, theidentity document including signed assertions corresponding toindependently verifiable data of the service consumer (processing block515); retrieving independently verifiable data of the service consumer(processing block 520); comparing the portion of the content of theidentity document associated with the service consumer received with therequest for credentials against the retrieved independently verifiabledata of the service consumer (processing block 525); generatingcredentials for the service consumer, if the portion of the content ofthe identity document matches the retrieved independently verifiabledata of the service consumer (processing block 530); and sending thegenerated credentials to the service consumer (processing block 535).

FIG. 6 illustrates a processing flow diagram for another exampleembodiment. In the embodiment 610 shown, a pool-based identitygeneration apparatus for service access performs the steps of:retrieving a credential associated with a service consumer, thecredential including signed assertions corresponding to independentlyverifiable data of the service consumer (processing block 615);generating a request for service including at least a portion of thecontent of the credential (processing block 620); sending the requestfor service to a service provider (processing block 625); and receivinga message from the service provider indicating that the requestedservice can be provided (processing block 630).

FIG. 7 shows a diagrammatic representation of a machine in the exampleform of a computer system 700 within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In alternative embodiments, themachine operates as a standalone device or may be connected (e.g.,networked) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client machine in client-servernetwork environment, or as a peer machine in a peer-to-peer (ordistributed) network environment. The machine may be a server computer,a client computer, a personal computer (PC), a tablet PC, a set-top box(STB), a Personal Digital Assistant (PDA), a cellular telephone, a webappliance, a network router, switch or bridge, or any machine capable ofexecuting a set of instructions (sequential or otherwise) that specifyactions to be taken by that machine. Further, while a single machine isillustrated, the term “machine” shall also be taken to include anycollection of machines that individually or jointly execute a set (ormultiple sets) of instructions to perform any one or more of themethodologies discussed herein.

The example computer system 700 includes a processor 702 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU), orboth), a main memory 704 and a static memory 706, which communicate witheach other via a bus 708. The computer system 700 may further include avideo display unit 710 (e.g., a liquid crystal display (LCD) or acathode ray tube (CRT)). The computer system 700 also includes an inputdevice 712 (e.g., a keyboard), a cursor control device 714 (e.g., amouse), a disk drive unit 716, a signal generation device 718 (e.g., aspeaker) and a network interface device 720.

The disk drive unit 716 includes a machine-readable medium 722 on whichis stored one or more sets of instructions (e.g., software 724)embodying any one or more of the methodologies or functions describedherein. The instructions 724 may also reside, completely or at leastpartially, within the main memory 704, the static memory 706, and/orwithin the processor 702 during execution thereof by the computer system700. The main memory 704 and the processor 702 also may constitutemachine-readable media. The instructions 724 may further be transmittedor received over a network 726 via the network interface device 720.

Applications that may include the apparatus and systems of variousembodiments broadly include a variety of electronic and computersystems. Some embodiments implement functions in two or more specificinterconnected hardware modules or devices with related control and datasignals communicated between and through the modules, or as portions ofan application-specific integrated circuit. Thus, the example system isapplicable to software, firmware, and hardware implementations. Inexample embodiments, a computer system (e.g., a standalone, client orserver computer system) configured by an application may constitute a“module” that is configured and operates to perform certain operationsas described herein. In other embodiments, the “module” may beimplemented mechanically or electronically. For example, a module maycomprise dedicated circuitry or logic that is permanently configured(e.g., within a special-purpose processor) to perform certainoperations. A module may also comprise programmable logic or circuitry(e.g., as encompassed within a general-purpose processor or otherprogrammable processor) that is temporarily configured by software toperform certain operations. It will be appreciated that the decision toimplement a module mechanically, in the dedicated and permanentlyconfigured circuitry, or in temporarily configured circuitry (e.g.configured by software) may be driven by cost and time considerations.Accordingly, the term “module” should be understood to encompass atangible entity, be that an entity that is physically constructed,permanently configured (e.g., hardwired) or temporarily configured(e.g., programmed) to operate in a certain manner and/or to performcertain operations described herein. While the machine-readable medium722 is shown in an example embodiment to be a single medium, the term“machine-readable medium” should be taken to include a single medium ormultiple media (e.g., a centralized or distributed database, and/orassociated caches and servers) that store the one or more sets ofinstructions. The term “machine-readable medium” shall also be taken toinclude any medium that is capable of storing, encoding or carrying aset of instructions for execution by the machine and that cause themachine to perform any one or more of the methodologies of the presentdescription. The term “machine-readable medium” shall accordingly betaken to include, but not be limited to, solid-state memories, opticaland magnetic media, and carrier wave signals. As noted, the software maybe transmitted over a network using a transmission medium. The term“transmission medium” shall be taken to include any medium that iscapable of storing, encoding or carrying instructions for transmissionto and execution by the machine, and includes digital or analogcommunications signal or other intangible medium to facilitatetransmission and communication of such software.

The illustrations of embodiments described herein are intended toprovide a general understanding of the structure of various embodiments,and they are not intended to serve as a complete description of all theelements and features of apparatus and systems that might make use ofthe structures described herein. Many other embodiments will be apparentto those of ordinary skill in the art upon reviewing the abovedescription. Other embodiments may be utilized and derived therefrom,such that structural and logical substitutions and changes may be madewithout departing from the scope of this disclosure. The figuresprovided herein are merely representational and may not be drawn toscale. Certain proportions thereof may be exaggerated, while others maybe minimized. Accordingly, the specification and drawings are to beregarded in an illustrative rather than a restrictive sense.

Thus, a computer-implemented system and method for pool-based identitygeneration and use for service access are disclosed. While the presentinvention has been described in terms of several example embodiments,those of ordinary skill in the art will recognize that the presentinvention is not limited to the embodiments described, but can bepracticed with modification and alteration within the spirit and scopeof the appended claims. The description herein is thus to be regarded asillustrative instead of limiting.

1. A method comprising: seeding an identity generator with a private key; retrieving independently verifiable data corresponding to a service consumer; using the independently verifiable data to create signed assertions corresponding to the service consumer; generating a non-portable identity document associated with the service consumer, the identity document including the signed assertions; signing the identity document with the private key; and conveying the signed identity document to the service consumer via a secure link.
 2. The method as claimed in claim 1 wherein the independently verifiable data corresponding to a service consumer includes an IP address of the service consumer.
 3. The method as claimed in claim 1 wherein the signed assertions are compatible with the security assertion markup language (SAML).
 4. The method as claimed in claim 1 wherein the method is performed at initial system/service deployment time.
 5. The method as claimed in claim 1 wherein the identity document is stored by the service consumer.
 6. A method comprising: retrieving a non-portable identity document associated with a service consumer, the identity document including signed assertions corresponding to independently verifiable data of the service consumer; generating a request for credentials including at least a portion of the content of the identity document; sending the request for credentials to an authentication authority; and receiving credentials from the authentication authority.
 7. The method as claimed in claim 6 wherein the independently verifiable data of the service consumer includes an IP address of the service consumer.
 8. The method as claimed in claim 6 wherein the signed assertions are compatible with the security assertion markup language (SAML).
 9. The method as claimed in claim 6 wherein the method is performed at system run time.
 10. A method comprising: receiving a request for credentials from a service consumer, the request for credentials including at least a portion of the content of a non-portable identity document associated with the service consumer, the identity document including signed assertions corresponding to independently verifiable data of the service consumer; retrieving independently verifiable data of the service consumer; comparing the portion of the content of the identity document associated with the service consumer received with the request for credentials against the retrieved independently verifiable data of the service consumer; generating credentials for the service consumer, if the portion of the content of the identity document matches the retrieved independently verifiable data of the service consumer; and sending the generated credentials to the service consumer.
 11. The method as claimed in claim 10 wherein the independently verifiable data of the service consumer includes an IP address of the service consumer.
 12. The method as claimed in claim 10 wherein the signed assertions are compatible with the security assertion markup language (SAML).
 13. The method as claimed in claim 10 wherein the method is performed at system run time.
 14. A method comprising: retrieving a credential associated with a service consumer, the credential including signed assertions corresponding to independently verifiable data of the service consumer; generating a request for service including at least a portion of the content of the credential; sending the request for service to a service provider; and receiving a message from the service provider indicating that the requested service can be provided.
 15. The method as claimed in claim 14 wherein the service provider verifies the credential against independently verifiable data of the service consumer.
 16. The method as claimed in claim 14 wherein the service provider checks access control data for a requested service and the service consumer via an authorization service.
 17. The method as claimed in claim 14 wherein the independently verifiable data of the service consumer includes an IP address of the service consumer.
 18. The method as claimed in claim 14 wherein the signed assertions are compatible with the security assertion markup language (SAML).
 19. The method as claimed in claim 14 wherein the method is performed at system run time. 